A common programming model is when one application “hosts” another application or applet where the character of the user interface changes as the hosted application is activated. One example is when a spreadsheet embedded in a word application is activated in order to manipulate the contents of the spreadsheet. When two applications want to present user interface (UI) elements to the user, conflicts can arise. One way of solving this was to hide conflicting information based on complex rules that could involve accessing the object model and/or modifying source code. OLE in-place editing technology has enabled two applications to behave as one by allowing one application to run within the frame of another. The user remains in the same frame window (within the context of the container) but is actually running another application (the server). Coordination between resources of the container and server applications is required to achieve this functionality. One of such resources is a menu.
Standard OLE menu merging allows container and server to merge their menus. However, the protocol does not handle extensive menu name collisions, except for the case of the “Help” menu. In cases when two functionally rich applications participate in menu merging, naming conflicts can be quite common. In one example, there can be a number of conflicting menus between two applications that have common menu items such as View, Tools, and Data. If these applications were to follow standard OLE menu merging protocol, the final menu would contain two identical “View” menus, two identical “Tools” menus, and two identical “Data” menu items. Moreover, usability studies show rather cumbersome and difficult usage where duplicate menus are involved. Users are frustrated when trying to accomplish tasks since there is no indication in UI which menu to use.
What is needed is an improved menuing system.